home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970326-19970626 / 000057_news@columbia.edu _Sat Apr 5 13:24:57 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  2KB

  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id NAA23467
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Sat, 5 Apr 1997 13:24:56 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id NAA19823
  7.     for kermit.misc@watsun; Sat, 5 Apr 1997 13:24:55 -0500 (EST)
  8. Path: news.columbia.edu!panix!news.eecs.umich.edu!news.mathworks.com!howland.erols.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  9. From: jrd@cc.usu.edu (Joe Doupnik)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: wanted: Refused Disposition explanation
  12. Message-ID: <1997Apr5.103337.96367@cc.usu.edu>
  13. Date: 5 Apr 97 10:33:37 MDT
  14. References: <859969673.27378@dejanews.com> <860140780.32126@dejanews.com>
  15. Organization: Utah State University
  16. Lines: 29
  17. Xref: news.columbia.edu comp.protocols.kermit.misc:6872
  18.  
  19. In article <860140780.32126@dejanews.com>, e.ingram@uk22p.bull.co.uk writes:
  20. > In article <5htrl1$gme$1@apakabar.cc.columbia.edu>,
  21. >   fdc@watsun.cc.columbia.edu (Frank da Cruz) wrote:
  22. >>
  23. >> Normally when you send a file, the disposition (what to do with the file
  24. >> when it arrives) is "store it on the disk".  However, Kermit can also send
  25. >> files with other dispositions, like "print", "send as e-mail", "submit as
  26. >> a batch job", etc.  If the receiver does not support the indicated
  27. >> disposition, or cannot handle the specifics (e.g. an invalid printer name
  28. >> was given for a print job), it refuses the file with reason: disposition.
  29. >>
  30. > In this instance, the default "store it on disk" disposition is in use.
  31. > Checks have been made on the target PC and there is no shortage of space
  32. > available. The target destination on the PC is *not* the root directory
  33. > so there can be no problem with the number of files present in the target
  34. > directory.
  35. > The connection between the systems is a dial_up line and is generally
  36. > reliable.
  37. > What circumstances might give rise to this type of transfer failure?
  38. ----------
  39.     Because MS-DOS must use DOS to access the file system then any
  40. blockage of writing to the named file will result in an error condition.
  41. Simply marking a file as read-only is sufficient. Similarly, if another
  42. program has the file opened for exclusive access then writing will be
  43. blocked.
  44.     Joe D.